Please take your time to read the following suggestion for improved clipboard handling!
One area that distinguished the Mac when it first arrived from other OS's of the day was that Apple gave developers guidelines to follow when creating a Mac application.
The idea was that by following Apple's guidelines the Mac would be the most integrated, compatible and easiest to use of computers. Those guidelines were incredibly far-sighted, but after all these years we all know that some areas are a little outdated.
One area where times have changed is the use of the clipboard, in particular, the DeskScrap. The DeskScrap has always been the easiest and most extensively used means for sharing data between applications.
You may already know the following 'Inside Mac' commandments:
1. If the user switches to another application, then your application receives a suspend event and should convert its private clipboard to the DeskScrap by calling PutScrap for each data type.
2. Your application should, at the very least, write either PICT or TEXT data and should be able to read either of these two via GetScrap.
3. It's the responsibility of the programmer to do as little computation as possible on receiving a suspend event (when the program gets switched to the background) to insure the best general responsiveness.
These 3 rules are direct from Apple circa 1984 but now in 1998 we face entirely different requirements. Now we have a System that allows running several programs at the same time, we have background tasks and network communication and in the near future we will have preemptive multitasking and memory protection. The above items, and there are probably others, are some of the reasons why the guidelines for the usage of the DeskScrap are outdated, why 1998 is not like 1984.
With all the new state of the art technologies several problems begin to appear.
Problem 1: "Keeping the clipboard data private is not multitasking friendly!" Consider the following scenario: Say Excel is running in the foreground and a background process (like CopyPaste or ClipFolio or an FKey) wants to act on the content of the clipboard. If the data is already in the DeskScrap, then everything is fine and the background program can do its job. If however the foreground program keeps the copied data private, then the only way to get the data is to send a suspend event message which makes the program think it is being switched to the background. According to the guidelines the program would then convert its private data to the DeskScrap. A program then goes thru a chain of time consuming changes: the toolbars will be hidden, the controls will be dimmed, the windows dragbar will be dimmed, any selections will be removed and finally (and most important for us) the private clipboard will get converted and put into the DeskScrap. Then the program gets a resume message and all these steps get reversed. This can take a few seconds in some large programs like Excel. This is boring for the user and annoying. This is entirely UNNECESSARY if a program supports the DeskScrap directly.
Solution 1: "Use PutScrap whenever the user copies a selection!" There are many programs on the market which do offer direct support. One that everyone knows is SimpleText and the other known well by most developers is CodeWarrior. If you copy a selection in either of these programs, the selection is sent directly to the deskscrap and any background process can access the data without needing to send a suspend/resume event. This is fast, efficient and good programming.
Problem 2: "Abuse of the DeskScrap for storing temporary data is misleading for other programs!" There are programs which do a terrible job. You copy a selection and they write fake data to the DeskScrap (DSIG, CLAP, WPD2, all are fake data types written by WordPerfect and MS Word). These programs need a suspend event before the fake data is replaced with the correct content. Dealing with these programs becomes a chore since each has to be treated in an individual manner thereby increasing the code and complexity of other applications and decreasing the overall stability and compatibility of the interacting applications.
Solution 2: "Use the DeskScrap only for copied data." Do not use the DeskScrap for any other purpose but storing the copied data. This data can then be correctly interpreted any time, even between restarts, at least by your application.
Problem 3: "The common data types sometimes do not store all the needed information" The types of data which get sent to the DeskScrap can be a problem. Many programmers think that writing 'PICT' or 'TEXT' or 'snd ' suffices because Apple said so in 1984. Not! Your own application should be able to restore the copied data exactly as it was when the user selected and copied it. If your program allows applying different styles on a selection of text it should also allow copying and pasting that text with styles. TEXT data alone won't be satisfying to the user who wants to move that to another application.
Solution 3: "You should provide additional data types like 'RTF ' or 'styl' or any other data type which allows your program to restore the data identically to the copied data."
Problem 4: "Assuming that your program alone is able to interpret copied data should not lead to the conclusion that the use of the DeskScrap is entirely useless" This problem we've noticed occurs way too often in music programs. Why don't music programs allow MIDI data to be copied and then pasted in other applications? For instance the user might want to use the Scrapbook to store MIDI sequences or the DeskScrap could be transferred to another computer (over the net) on which another copy of your program is running or it could be stored in a scrapbook for later use in your program. Anyone working at one of these companies who wants to advance their field should request a copy of CopyPaste from us to see in a very concrete way why using the clipboard in a music program should be exactly like in a word processor.
Solution 4: "The minimum you should provide is a private type of data for the DeskScrap which at least your program can understand!"
Problem 5: "Some programs provide plenty of data for the deskscrap but when this data is pasted their own program its not able to interpret its own data correctly." If your program politely provides a dozen data types for the DeskScrap, then it should always be able to interpret them correctly later. We have seen programs which provide TEXT and PICT data when text was copied, but pasting the same data only inserts a picture! This is annoying for the user.
Solution 5: "Try to interpret the data retrieved from the DeskScrap as if it was copied from your own program and use the same priority for the interpretation of this data."
Problem 6: "Some programs do not care about changed DeskScrap data." Sometimes programs do not examine the DeskScrap for changes. Even if they provided clipboard data after a copy, they refuse to use their data types when they are stored in the DeskScrap.
Solution 5: "Always examine the data in the DeskScrap and see whether you can interpret this data in your program."
The most frustrating experience in the development of CopyPaste was the fact that a few of the most successful programs (MS Word, Excel, WordPerfect, Photoshop, Illustrator and a few others) do not appear to care about the usage of the clipboard across different applications. 90% of the development time in creating CopyPaste was devoted to these idiosyncrasies. Programmers of other clipboard tools also suffer from these problems and lastly the user suffers with the remaining incompatibilities.
The clipboard nowadays is taken for granted but it's the foundation of integration in a modern OS. We can take another big step forward on the Mac and give users a whole new level of ease and power by following the rules above. Any application programmer with a question should contact us at the e-mail addresses below. Any application programmer who will follow our advice can have a free registration to CopyPaste.
Any programmer who follows the above points will be hailed as the supreme giver of clipboard nirvana. People worldwide will start to sing the praises of your program, money will rain down from the heavens and you will live to a ripe old age admired and respected by all who know you.
Please pass this message on particularly at Apple, Microsoft, Adobe and Corel. Thanks for listening.
